The ever increasing reliance on information and the computing systems that produce, process, distribute, and maintain such information in its myriad forms continues to put great demands on techniques for data protection. Simple systems providing periodic backups of a computer system's data have given way to more complex and sophisticated data protection schemes that take into consideration a variety of factors including: the wide variety of computing devices and platforms encountered, numerous different types of data that must be protected, the speed with which data protection operations must be executed, and the flexibility demanded by today's users.
Of particular interest to many businesses are databases, for which availability to the users can be mission critical. If, for example, a bank cannot process customer transactions (deposits, payments, transfers, etc.) because of a database failure, a customer may be unable to accomplish its business. Likewise, if an airline is unable to book reservations, customers may be lost and its planes may fly empty. These examples illustrate the need to quickly and efficiently be able to restore functionality to applications accessing computer data.
Information Systems managers perform backup and restore operations to protect critical data. The backup and restore process allows for the restoration of data over a wide range of potential system problems, including media failure, user errors, or loss of database servers. In addition, backing up and restoring data is useful for other types of problems not related to system failure, such as moving or copying a database from one server to another.
Backing up data makes a copy of the data that can be used to restore the data. For databases, there may be several different types of backups of the database data, such as full, differential, and component backups. A full backup is a copy of all the data within a database at a particular point and time. A differential backup is a backup of the differences in content between the current time and the last full or differential backup, and is typically implemented by only backing up changed data. There are two types of differentials: cumulative and non-cumulative. A cumulative differential backup includes all of the changes since the last full backup. A non-cumulative differential backup only includes changes since the last differential backup.
Backups are not restricted to the complete database but also may be focused on selected components of the database. Components may be hierarchical portions of the data as demonstrated in FIG. 1(a). In FIG. 1(a), the data 100 is divided into two components: 110 and 120. Those components are then broken down into subcomponents, e.g., 110(a) and 110(b). The data can be broken down into a hierarchy consisting of the quantity and number of levels of components as make logical sense for an application using the data. A backup scheme may be devised in which each component is backed up separately on its own time schedule, which may be based upon a number of factors, including for example, criticality of the data, frequency of data modification or addition, and location of the particular component within a network. Examples of component structure in a database environment include file groups and files as in Microsoft SQL Server™ and table spaces and file components in Oracle® databases.
During a database backup, components of the database are copied, including any needed portions of the transaction log. The transaction log is a serial record of modifications that have occurred in a database and includes information such as which transaction performed each modification. The transaction log typically is used in restore operations to roll forward completed transactions and to roll back or undo uncompleted transactions. A transaction log backup typically records only the changes that have occurred in the transaction log after a prescribed synchronization point. It is not an actual backup of the database itself.
In the event of a data failure, that data should quickly and efficiently be restored to a desired state and time. In general, a restore operation involves the application of one or more backups of, for example, a database. Restoring a database backup returns the database to its state when the backup was created. Any incomplete transactions in the database backup are typically rolled back to ensure that the database remains internally consistent. Restoring a transaction log backup can reapply all completed transactions that are in the transaction log to the database. When applying a transaction log backup, the transaction log is traversed, and all transactions in the log are rolled forward. When the end of the transaction log is reached, the database is restored to the state in which it was when the transaction log backup operation began. The restore operation then rolls back all transactions that were incomplete when the backup operation started.
Database backups and transaction log backups are used together to restore a database to its state at a point and time at which a failure occurred. Typically, this involves working backwards from the desired restore time through many incremental or full backups, along with the transaction log, to completely recreate the database as of the desired time. In a complex environment where component backups are used, restore operations also involve determining the complete set of backups of the various components taken at various times. In order to ensure consistency of the data, it is desirable that the compositional structure of the database be consistent throughout all the backup sets used to recover the data.
Accordingly, it is desirable to have an efficient method of determining the appropriate set of backups that correspond to a consistent collection of data components when restoring data to a particular state.